I don't know if there's more of these but these imports aren't resolving for me. I think because it's reaching into the features module. VScode import resolving doesn't seem to know what to do here either

Looks like a circular dependency, surprised it built. I guess I'll need to go through every file in vscode to check for this, or run a tool somehow.

I asked my free trial friend for a clearer explanation:

The app build uses web/apps/wps-web/tsconfig.app.json:8, which explicitly maps aliases like api/*, utils/*, and components/* straight to sibling source folders:
  - web/apps/wps-web/tsconfig.app.json:10
  - web/apps/wps-web/tsconfig.app.json:17
  - web/apps/wps-web/tsconfig.app.json:20

  and it includes those package source directories directly:

  - web/apps/wps-web/tsconfig.app.json:25

  So @wps/wps-web is effectively compiling:

  - its own src
  - packages/api/src
  - packages/ui/src
  - packages/utils/src
  - packages/types/src

  as one combined source tree.

  That is why yarn build works.

  Why root tsc -b tsconfig.json fails:

  - that command tries to typecheck the package projects as separate units
  - those package projects are not actually self-contained yet
  - so the monorepo graph fails even though the app graph passes

  Short version: the app builds because it is still “cheating” in a practical way by directly consuming raw source from the sibling folders, instead of consuming real
  isolated packages.

I fixed this one here: 49bcfb1, will address the rest in a follow up commit(s).

This is the only package that's actually installed as a package, so I think the repo still relies on relative imports rather than consuming packages as packages. Is that by design?

Does the turbo repo caching of packages work in a set up like this?

Oh good catch, yeah these should be installed as packages or turbo caching won't work.

Fixed in: 444b988 and 96597cd

Each package build just runs a type check without emitting,outputs: [] tells Turbo "there are no output files, but still cache the result of this task". So Turbo caches the exit code and considers the task successful on a cache hit, skipping the tsc --noEmit run entirely. The type-check won't re-run unless the inputs (source files) change.

Aren't all the imports still relative though? To import from the api package wouldn't it need to be something like @wps/api/.... And in that case if they're actual packages don't they need to export something?

Also curious about how vscode quick fix imports work in this case

This turborepo example repo might be helpful? Not sure
https://github.com/vercel/turborepo/blob/main/examples/basic/packages/ui/package.json

Check the latest now, packages are used and aliases are gone.

I see this in vscode, should this be a trusted domain? Is it necessary?

Unable to load schema from 'https://turbo.build/schema.json': Location https://turbo.build/schema.json is untrusted.

$schema is for editor tooling — VS Code uses it to validate keys like tasks, dependsOn, outputs etc. Whether to trust the domain is up to you. It's Turborepo's own schema URL, so it's not suspicious.